Veritas NetBackup™ 状态码"十大"常见报错状态码

我在刚开始学习Netbackup的时候，没少走弯路。经常会遇到各种稀奇古怪的 error 信息，遇到报错会很慌张，急需一个解决问题的办法。跟无头苍蝇一样，会不加思索地把错误粘到百度上，希望赶紧查找一下有没有好的处理问题的方法。

今天就给大家列举 Netbackup中，最经典的十大错误案例，并附有处理问题的解决思路和方法，希望能给刚入行一些帮助，今后再遇到任何报错，我们都可以很淡定地去处理。

学习任何一门技术的同时，其实就是自我修炼的过程。沉下心，尝试去拥抱技术的世界！

（在执行请求的操作的过程中， 检测到一个可能需要更正操作的问题。）

解决方法：    

1、确保该备份文件当前未被使用或修改。 检查文件或目录路径的长度是否超过了 1023 个字符。无法打开文件。检查文件的权限或目录中是否有隐藏文件

 如果是Archivelog备份，而且后续的备份均返回1。通常情况，需要进行Oracle 数据库的Archivelog同步。

Oracle数据库Archivelog同步的方法为：

以Oracle数据库用户登录到Oracle数据库服务上，通过RMAN来运行下面的命令：

$ su – oracle

$ rman

RMAN> connect target /

RMAN> change archivelog all validate;

RMAN> exit

 如果是数据库在线全备份，需要查看备份脚本所在目录中的.out输出文件，查看哪部分没有备份成功，再进行相应处理。

（备份或存档操作未备份文件列表中的任何文件。

此状态码主要在以下情况下出现：在使用 Lotus Notes 或 SQL Server 数据库代理进行自动备份时，所有与该作业相关的备份均已失败。或者，Enterprise Vault 备份已失败。在进行标准文件系统备份时不会出现该状态码。

如果在进行 UNIX、Linux 或 Windows 文件系统备份时遇到此错误，或者在 SQL Server 或 Lotus Notes 以外的数据库代理中发生此错误，请打开技术说明 TECH38838) 中推荐的 NetBackup 支持案例。） 

解决方法：

根据需要，执行以下操作：

在 UNIX 上，如果没有为 Lotus Domino Server 启用存档式日志记录，则会发生此错误。如果正在对事务日志进行另一个备份操作，也会发生此错误。

单击此处查看 Veritas 知识库中有关此状态码的技术说明和其他信息。

客户端空间不足、卡进程、sql服务没有启动

出现在sql数据库，客户端名字带域名，去客户端设置里修改

看看磁盘使用情况

看看脚本是否正常（注册表）

看看客户端与SQL的连接是否已认证（SQL代理服务器）

（所出现的错误导致用户备份失败。） 

解决方法：

验证您是否具有读取这些文件的权限。检查文件读取权限或 Windows上的用户权限。

对于 数据库扩展客户机 （如 NetBackup for Oracle），这可能意味着 控制备份的脚本出现问题。详细信息请查看脚本的 Out 文件和错误信息。

oracle归档问题，试试能否全备成功，oracle交叉验证

rman target /

allocate channel for maintenance device type disk connect 'sys/abc123@nfjd1';//改节点

crosscheck archivelog all;

delete force expired archivelog all;

也有可能是客户端验证失败，在netbackup client service重新验证一下。（.out文件报错ORA-03113）

也有可能是文件夹权限不足，开发/usr/openv文件夹权限后再进行oracle_link（.out文件报错ORA-19554）

（ 无法读取某个文件或套接字。） 

可能的原因如下：

请参见 NetBackup for Enterprise Vault Agent 管理指南的“故障排除”一节。

在 NetBackup 活动监视器中，详细状态日志可能包括如下类似消息：

12/05/2014 06:43:53 - begin writing

12/05/2014 06:48:53 - Error bpbrm (pid=2605) socket read failed:

errno = 62 - Timer expired

12/05/2014 06:48:55 - Error bptm (pid=2654) media manager terminated

by parent process

/NetBackup/logs/vxms 日志可能包含类似如下 VDDK 消息的重复实例：

12/08/2014 05:11:35 : g_vixInterfaceLogger:libvix.cpp:1844 :

[VFM_ESINFO] 2014-12-08T05:11:35.146-06:00 [7F1B1163F700 info Libs']

FILE: FileLockWaitForPossession timeout on '/var/log/vmware/hotAddLock.

dat.lck/M34709.lck' due to a local process '15882-26732358(bpbkarv)'

解决方法：

根据需要，执行以下操作：

请参见 NetBackup 故障排除指南中的“解决网络通信问题”。

Mar 24 01:35:58 bison unix: WARNING: sn_alloccache: cache

/dev/rdsk/c0t2d0s3 full - all snaps using this cache are now

unusable

此错误指示缓存分区不够大。如果可能的话，请增大缓存分区的大小。或者，如果多个备份使用同一个缓存，请减少并行备份的数量。要减少并行备份的数量，请重排其中的一些备份，或者将整个备份重排到文件系统活动较少的时间进行。

请参见 NetBackup 故障排除指南中的“对网络接口卡性能进行故障排除”。

该日志可能会指出下列情况：

如果磁盘是 IDE 驱动器，则在 /usr/openv/ netbackup/logs/ bpfis 日志中可能会看到下列内容：

get_disk_info: FTL - /var/tmp/caa026fEU disk_inquiry failed.

Errno = 25: Inappropriate ioctl for device

在 /usr/openv/netbackup/logs/bpbkar 日志中可能会出现下列内容：

bpbkar: INF - Processing /var

bpbkar: ERR - get_disk_info() failed, status 13

bpbkar: ERR - tpc_get_disk_info() failed: err 13

bpbkar: ERR - bpbkar FATAL exit status = 13: file read failed

bpbkar: INF - EXIT STATUS 13: file read failed

要增大所有客户端的客户端读取超时，请在“NetBackup 管理控制台”中，转到“主机属性”>“主服务器”>，双击主服务器，然后转到“属性”>“超时”。然后增大客户端读取超时。

在 NetBackup 管理控制台中，单击“NetBackup 管理”>“主机属性”> 双击主服务器 >“超时”>“客户端读取超时”。

单击此处查看 Veritas 知识库中有关此状态码的技术说明和其他信息。

( 系统函数 gethostbyname() 未能找到客户端的主机名。)

解决方法：

在下列位置验证客户端名称是否正确：

在 UNIX 客户端上，验证客户端的主机名是否在 /etc/hosts 文件、YP hosts 文件或 NIS 映射中。

单击此处查看 Veritas 知识库中有关此状态码的技术说明和其他信息。

(客户机拒绝 bpcd 端 口号上的连接。)

解决方法：

发生这种情况的原因可能是 在该 bpcd 端 口没有进程监听，或者因为到该 bpcd 端 口的连接太多，超过了 网络子系统使用 listen()调用可以处理的数量。

(文件列表中的文件与客户机上的任何文件都不匹配。)

解决方法：

验证是否为此客户机指定了正确的文件列表。

在 Windows 客户机上， 验证用来启动 NetBackup 客户机服务的帐户 是否有读取这些文件的权限。

(以下是出现此状态码的可能原因：

解决方法：

根据需要，执行以下操作：

NetBackup 可能无法获取驱动器的卷 ID。在此情况下，将不会备份任何虚拟机驱动器。备份失败，NetBackup 状态码为 156。

驱动器可能会关闭。

每次只能对一个虚拟机运行一个备份。如果在第一个备份处于活动状态时启动虚拟机的第二个备份，则第二个作业将失败，状态码为 156。

推荐的操作：请等到第一个作业完成后再运行第二个作业。

NetBackup 无法查找备份策略中列出的虚拟机的主机名或 VM 显示名称。详细状态日志可能包含以下错误消息：

Critical bpbrm (pid=) from client :

FTL - snapshot creation failed, status 156.)

如果虚拟机没有静态 IP 地址，可以将 NetBackup 配置为通过虚拟机的 VM 显示名称或 UUID 来识别虚拟机。不使用静态 IP 地址的环境包括群集和动态分配 IP 地址的网络等。

请注意，可能已将 NetBackup 配置为通过虚拟机的 VM 显示名称来识别虚拟机。在这种情况下，请确保显示名称是唯一的，且不包含特殊字符。

通过 vCenter Server，NetBackup 可以备份已关闭的虚拟机。必须为 NetBackup 提供用于访问 vCenter Server 的凭据。

如果 NetBackup 使用 ESX Server（而不是 vCenter）的凭据，则可能无法识别已关闭的虚拟机。请注意以下几点：

如果具有独立磁盘的虚拟机处于暂停状态，则快照作业将失败。作业详细信息日志中将出现类似下面的消息：

01/12/2015 17:11:37 - Critical bpbrm (pid=10144) from client

: FTL - VMware error received: Cannot take a

memory snapshot, since the virtual machine is configured with

independent disks.

以下 VMware 文章中提供了更多信息：

http://kb.vmware.com/kb/1007532

解决方法是，将虚拟机的状态更改为打开或关闭，然后重新运行备份。

注意:

不能使用快照捕获独立磁盘中的数据。将会备份虚拟机的其余数据。

将忽略 RDM（不备份），并重新创建任一独立磁盘，但该磁盘是空的。

如果尝试创建虚拟机的快照超出 10 秒的 VMware 超时，快照将失败，并显示 NetBackup 状态 156。如果虚拟机配置了大量的卷，可能会发生该超时。请注意，即使禁用“虚拟机静默”选项，仍可能会遇到超时问题。

执行以下操作之一：

没有 vmdk 文件的虚拟机可以出现在 vCenter Site Recovery Manager (SRM) 环境中。如果复制虚拟机从未处于活动状态，则它处于被动模式，且可能没有 vmdk 文件。

您可以在策略的“VMware 高级属性”选项卡上启用“忽略无盘 VM”选项。如果启用此选项：在 SRM 环境中，如果该虚拟机没有 vmdk 文件，NetBackup 就不会备份复制（被动）虚拟机。

只要发生 VMware 快照，就会为每个 vmdk 创建一个 delta.vmdk 文件。如果单个 vmdk 文件存在 32 个或更多此类增量文件，则 NetBackup 对该 VM 的备份可能会失败（状态为 156）。NetBackup 活动监视器的作业详细信息包含类似以下内容的消息：

02/06/2015 10:33:17 - Critical bpbrm (pid=15799) from

client fl5vm1_2012: FTL - vSphere_freeze: Unable to proceed with

snapshot creation, too many existing delta files(44).

02/06/2015 10:33:17 - Critical bpbrm (pid=15799) from client

fl5vm1_2012: FTL - VMware_freeze: VIXAPI freeze (VMware snapshot)

failed with 25: SYM_VMC_FAILED_TO_CREATE_SNAPSHOT

02/06/2015 10:33:17 - Critical bpbrm (pid=15799) from client

fl5vm1_2012: FTL - vfm_freeze: method: VMware_v2, type: FIM,

function: VMware_v2_freeze

要备份 VM，请执行以下操作：

在 VMware 界面中，右键单击 VM 并选择“快照”>“合并”。有关更多信息，请参见 VMware 文档。

如果快照合并失败，请参见以下 VMware 文章以获取更多帮助：

http://kb.vmware.com/kb/1004545

如果 NetBackup 策略可用于虚拟机静默（默认），vSphere 中的 VMware 快照操作将启动虚拟机静默。如果快照静默失败，则 NetBackup 作业失败，状态为 156。

请参见 NetBackup for Enterprise Vault Agent 管理指南的“故障排除”一节。

请参见下列指南之一的“故障排除”一节：

如有必要，提高日志记录级别并重试该作业。

请参见 NetBackup 日志记录参考指南中的“关于日志”。

单击此处查看 Veritas 知识库中有关此状态码的技术说明和其他信息。

(备份调度程序对其进行排队的备份或归档操作没有尝试执行，因为 备份时段不再打开。)

解决方法：

请检查是否有进程卡死，一直占用驱动器。

如果有重启备份服务器或 介质服 务器的服务，重试备份。

如果可能， 更改日程表， 为此策略和日程表组合延长备份时段的时间， 以便不再出现此错误。 如果必须运行该备份，请使用 “备份策略管理”窗口策略(Policy)菜单上 的手动备份(Manual Backup) 命令执行该备份。手动备份将忽略备份窗口。

消息： 资源请求失败 

( nbjm 进程无法获取作业所需的资源。此状态码附带有 EMM 原因字符串，该字符串出现在活动监视器的作业详细信息屏幕中以及 nbjm 调试日志中。EMM 原因字符串确定失败的资源请求的原因。)

解决方法：

找到 EMM 原因字符串，更正问题，然后重新运行该作业。

对于某些通用的 EMM 原因字符串（如“磁盘卷已关闭”），可能需要生成某些报告来确定失败原因。可以通过在“NetBackup 管理控制台”中使用 bperror 或者各种日志条目报告（如“报告”>“磁盘报告”>“磁盘日志”）来生成此类报告。

单击此处查看 Veritas 知识库中有关此状态码的技术说明和其他信息。

今后还会继续总结 Netbackup中的各种报错处理思路与方法，希望跟各位老铁们，同学们一起努力。多沟通多交流！